隔空抓藥的每一天，來看病的病人來自世界各國都有，有語言能通的客人，也有語言不通的客人，還有語言不通但是硬要用國際語言看病的病人。

就看醫生在看病一樣，客人上門第一件事除了在櫃台付錢最重要的就是填寫病歷。

如果你的客人往往就是一通電話或是一件郵信裡的三兩句話，某某機器壞了，什麼服務不能用，某某網站連不上，讓你立馬過去還真的會忙不完。因此除非你是被要求隨傳隨到的工作類型，在上門前或是開始處理問題前，先讓你的客人提供一些基本資訊真的是個省時省力的起手式。

大一點的公司可能有辦法生一個系統出來，讓對方註冊帳號，在系統上填寫資料。沒有系統的話其實也無所謂，重要的資訊終歸是要提供的，就回歸原始的word/excel表格，最後再自己手動做彙整。

今天便是要來討論下，這份表格裡該留下什麼重要的資料。

• 基本資料

  唯一識別：

  首先是問題的本體發生在那個主題，硬體面的問題的話，那這邊就是機器的序號；
  如果偏軟體網路面的話，IP或是主機名稱便可以先當這類問題的唯一識別。
  但是只留這兩個名稱最大的缺點就是，偶爾會有遇到客人弄錯機器但是你無法查證的情況，因此後續我們還會請客人提供再細節一點的資訊來交互比對資料的正確性。
  

  平台運作的版本：

  硬體面上會需要提供相關硬體的FW revision, 軟體網路層面的話就是OS的版本與build number
  

• 問題描述

  錯誤訊息：

  這邊最好讓客人以任何不拘形式的log(文件、圖片、影片)來提供他們所看到或是認知的錯誤，可以的話最好也提供客人預期的行為或是一份正常的的畫面或是log做為比對
  

  複製步驟：

  如果是客人有辦法重複操作重現的問題，有詳細的步驟會方便我們在實驗室或是自己手上的機器驗證，就算是無法複製的問題也請客人盡量仔細的回想發現問題的過程
  

  發生頻率/範圍：

  這個項目在大量的錯誤被回報時，非常重要，可以用來理解問題有沒有特定發生的時間點或是頻率(例如每周固定何時發生？每個月固定的日期？或是固定的發生的間隔(7天或是30天)？像是集中在假日發生時，可能與使用者端的固定排程有關)。
  
  另一方面也能協助我們做一些初步的判斷與建議，如果發生機率很低、影響程度不大或是樣本數很少的狀況下，也可以視客人的情況先做硬體的更換，或是擬定觀察與追蹤的方針。
  

  系統開始正常運作日期/上一次已知正常時間：

  當收到一個問題的回報，先了解問題發生的背景可以減少很多繞遠路或是無效的檢查的時間。
  使用者做了什麼行為導致發現這個問題，這個行為通常是還在系統部署的階段或是系統已經運行一陣子才會執行對於troubleshooting接下來該做什麼是有很大的影響的。
  

• 詳細硬體資訊

  FRU:

    FRU是一個廠商會將機器生產的硬體相關設定或是資料存放的位置，裡頭如果有錯誤的資料可能會導致機器的軟硬體運作不正常，同時也會影響機器後續維護的管理。
  

  HW configuration:

    讓客人將機器上頭詳細的CPU/MEMORY/HDD等等型號或是料號做清楚的紀錄，同時也要給出清楚的安裝位置，包括插槽的位置
  

  FW settings:

    機器本身的BIOS/BMC設定可以洽詢廠商如何做匯出備份，其他FW的話就需要一個個使用對應的FW tool來匯出，比較大的品牌廠商甚至會設計自己專用的工具來做一整份軟硬體log的輸出。
  

  HW/FW log:

    新的伺服器都有內建BMC，平時會紀錄很多重要的HW log，因此這是個很快速可以先排除HW問題的起點。
    FW log的話會建議先詢求廠商的協助，畢竟FW tool會有版本與新舊的差別，有時甚至會需要用生產工具做詳細的分析。
  

• 詳細軟體資訊

  Software/Driver revision:

   當問題牽扯到軟體時，上頭搭載的許多軟體與驅動程式的版本也需要一同考慮進去，有時甚至是軟體之間的互相影響導致不正常的行為，常見的例子像是防毒軟體或是EDR軟體，網路環境的話IPS/IDS和Firewall也常常會因為rule的不熟悉或是軟體更新，而有誤擋的情形。
  

  Tool revision:

    除了懷疑網路、軟體、HW之外，tool的bug也是個必需要考慮的因素之一，因此把tool的版本詳細的記錄，有時稍微google一下就能發現你並不孤單。
  

  Software log:

    這一點和FW log有點類似，software log在之前的文章中有提到，有時不是那麼的集中與確定他們存放的位置，因此也是建議與廠商連絡，一方面如果不確定跟HW或是SW比較有關的話，也可以各自請廠商分析後，互相參考。